Add compatibility with NP2020 probes#435
Add compatibility with NP2020 probes#435chrishalcrow wants to merge 4 commits intoSpikeInterface:mainfrom
Conversation
|
SI must be able to parse SpikeGLX data with either the 'old' imro format that has a type code, or the new with pn. It isn't just custom made imros that may have type codes. All SpikeGLX made data before version 20260115 will have type codes, which will be 95% of all data for a long while because people don't update software very often. So any imro reader needs to accept and parse either format. Look at the first item in the imro header as a string. (1) If it starts with a non-number (doesn't have to be an 'N') assume it is a pn. If you wish to validate the imro compatibility, this pn should match the pn in the metadata (which must also exist). Interpret the imro data according to the format spec for that pn in the probe table. (2) If the imro header value is a pure number it is a type code and this can be handled as you had been. Case (2) is now the 'legacy' case even though it will dominate for many months. |
2 participants
As per #432, there are some small changes to the imro format. Primarily,
probe_typeis no longer being used. We will keep it inread_imroin case users have constructed custom imro files for their own setups and are using the probe type key.In this PR, I remove an unnecessary cast to int for the probe type (in the
_parse_imro_stringthe cast value was never used. Inread_imroit was immediately cast back to string). This allows the new imro files to be read without any other changes (nice!!).Then I add some test data, supplied by @jenniferColonell and @billkarsh (thanks!)